The present invention lies within the field of securing electronic devices e.g. terminals or smartcards, comprising several execution environments of which at least one is a trusted execution environment and another is a Rich-OS execution environment.
A trusted execution environment is implemented by means of a secure processor, possibly being a processor dedicated to this task or possibly having other functions, and a secure rewrite non-volatile memory; it is based on a trusted operating system. Therefore applications depending on the trusted operating system originate from trusted or certified sources over which the user of the terminal has no control.
Similarly, a Rich-OS execution environment is based on a rich operating system allowing the execution of applications of various origins such as the Internet.
These two operating systems may be executed for example on one same chipset of the terminal.
In addition, the trusted operating system has a secure start-up mechanism which verifies that the electronic device starts up in trusted state, by verifying the integrity of the code executed on the electronic device, in particular the code of the trusted operating system. The trusted operating system starts up before any other operating system starts up beforehand.
If the Rich-OS operating system is corrupt the security of terminal data is no longer guaranteed. To solve this problem, it is known fully to disable the Rich-OS operating system. However this is not a convenient solution for human users since they can no longer use their terminal which is evidently not desirable especially in the event of an emergency (call to an emergency number impossible).
Also, electronic devices are known which comprise secure elements such as a SIM (UICC) card which is a removable secure element, or an embedded secure element eSE.
Document US 2002/0186845 proposes a system for disabling access to a secure element of a terminal by sending a blocking message via radio, nevertheless allowing the use of some functions of the terminal which then functions in fail-soft mode.
However, in the solution disclosed by this document, the task of signalling a security anomaly is up to the user of the terminal and securing of the terminal only takes place insofar as it is requested by the user. Therefore, when the terminal encounters a security anomaly transparent to the user i.e. which goes unnoticed, securing of the terminal does not take place. In addition, the solution proposed in the aforementioned document entails the need to be able to receive a radio signal. Therefore in the case in which the user uses the terminal with insufficient network connection (e.g. network hole or faulty network) or no network connection (e.g. in aircraft mode) securing of the terminal cannot be made.
As a result there is a need to improve on existing methods for securing electronic devices.